With the advent of personal computer system use in every day personal and business affairs, the issue of computer security has become critical. To protect the information contained in the personal computer system, which in many cases may be highly sensitive and confidential, embedded security subsystems (“ESS”) have been developed.
An ESS is typically a chip coupled to a processor in the computer. The ESS is independent from the computer's operating system, and therefore, is incorruptible from the operating system. The ESS is utilized generally according to the standards developed by the Trusted Computing Platform Alliance (TCPA), which is an open association of technology companies working to improve computer-platform security. The TCPA has developed an innovative trust model for computing platforms, including hardware capabilities, to make protections stronger.
FIG. 1 is a block diagram of a computer system 10 utilizing an ESS 40 in accordance with the TCPA trust model. As is shown, the computer system 10 includes a processor 20 coupled to a BIOS 30 and an ESS 40. The BIOS 30 typically performs a Power-on Self Test (POST) and ensures that hardware devices, such as a floppy drive 50 and hard drive 60, are functional. Memory 70 is coupled to the BIOS 30 to store code loaded from the hardware devices during POST. The BIOS 30 includes a boot block 32 and a main BIOS 34. The ESS 40 includes a plurality of protected control registers (PCRs) 42, at least one 42a of which is dedicated to the booting process.
In FIGS. 2A and 2B, a flowchart illustrating a conventional boot process 100 utilizing the ESS in accordance with the TCPA trust model is presented. The process 100 begins when the computer is reset in step 110, e.g., the computer is powered-up. In step 112, the PCR(s) 42a dedicated to the booting process is reset to zero. Before the code in the boot block 32 is executed, the code is hashed to produce a digest value, which is then extended to the PCR 42a, via step 114. Then, in step 116, the code in the boot block 32 is run, which passes control over to the main BIOS 34. Nevertheless, before executing the code in the main BIOS 34, that code is also hashed and the value extended to the PCR 42a in step 118. Then, in step 120, the code in the main BIOS 34 is run.
As with most typical boot processes, the BIOS 30 will perform a Power On Self Test (POST) for all of the different hardware components in the system to ensure each component is working properly. Thus, the BIOS 30 will determine which devices, e.g., floppy drive 50 and hard drive 60, are bootable, list them in a boot table, and then initiate the boot sequence.
Referring now to FIG. 2B, the process 100 continues at number B. Starting with a first device in the boot table, the BIOS 30 attempts to read the device (step 122) to determination whether the device is bootable (step 126). If the device is not bootable, then the boot table is incremented by one and the BIOS 30 attempts to read the next device (step 122). If the device appears to be bootable (step 126), then the BIOS 30 will hash code from the device and extend the value to the PCR 42a in step 126. The BIOS 30 will then load the code and execute this code in step 128). At this point, the code in the device is now in control of the system. The device will then make a determination of whether it is bootable in step 130. If the device code determines that it is not bootable, then it will return control back to the BIOS 30 by generating an interrupt signal, such as an interrupt 18h, via step 132. The BIOS 30 will increment to the next boot device in step 134. If, on the other hand, the device code determines that the device is bootable (step 130), the device will boot an operating system, via step 136.
Once the operating system has been booted, the process 100 continues at number C. This part of the process, illustrated in FIG. 2C, verifies the trustworthiness of the boot sequence. The value(s) in the PCR(s) 42a is a reflection of the boot process from beginning to end. In step 142, the value(s) in the PCR(s) 42a is compared to a predetermined value that reflects a trustworthy boot sequence. The predetermined value is typically calculated by the operating system.
If the PCR 42a value is not equal to the predetermined value calculated by the operating system (step 144), the operating system will be required to initiate a security check in step 148 to examine the boot process to determine whether a security breach has occurred. Additional logic must be provided in the operating system to perform this check.
If a device was determined by BIOS 30 to be bootable and the device ended up returning to BIOS 30 through the interrupt signal, then the PCR 42a value will differ from the predetermined value. Thus, while the boot process might be trustworthy, the operating system will nonetheless be required to initiate the security check. Moreover, because the code from a nonbootable device has been loaded from that device, there is a chance that destructive code from that device remains in system memory 70, where it can potentially cause harm.
Accordingly, a need exists for handling nonbootable devices identified during the boot process and for protecting the computer system without requiring additional logic in the operating system. The present invention addresses such a need.